本文|根源_性能监控

篇首语：本文由编程笔记#小编为大家整理，主要介绍了性能监控相关的知识，希望对你有一定的参考价值。

 工欲善其事必先利其器&＃xff0c;性能优化和故障排查在我们大都数人眼里是件比较棘手的事情&＃xff0c;一是需要具备一定的原理知识作为基础&＃xff0c;二是需要掌握排查问题和解决问题的流程、方法。本文就将介绍利用性能监控工具&＃xff0c;帮助开发者更快更准的找到问题产生的根源。本文分为三部分&＃xff0c;第一部分将介绍在Linux环境下的常用监控工具&＃xff0c;第二部分介绍Windows环境下的监控工具&＃xff0c;第三部分将通过一个案例&＃xff0c;介绍利用这些监控工具一步一步找出java应用程序的问题。

Linux环境下的监控工具

  需要先声明的是&＃xff0c;下面介绍的部分工具其实在Liunx环境、Windows环境下都可以使用&＃xff0c;只不过在不同的环境下使用什么工具更合适。

  下面我们想象这么一个场景&＃xff1a;有一天运维人员看到生产环境下的服务器负载升高、CPU飙升&＃xff0c;内存占用增大&＃xff0c;请问接下来他该怎么办&＃xff1f;可能有人会说&＃xff0c;那就找到负载升高、CPU飙升。。的原因啊&＃xff0c;如果是应用程序造成的就把它kill掉。如果采用这种方法&＃xff0c;问题可能会短时间解决&＃xff0c;但带来的问题是应用在一段时间不可用&＃xff0c;并且我们没有找到问题发生的根源&＃xff0c;下次重启后&＃xff0c;问题依然会产生。那么如果出现类似的问题&＃xff0c;严格的排查流程是怎样的呢&＃xff1f;在回答这个问题之前&＃xff0c;我们先了解一下Linux上常用的几个监控工具&＃xff1a;

uptime

该命令将显示目前服务器持续运行的时间&＃xff0c;以及负载情况。

通过这个命令&＃xff0c;可以最简便的看出系统当前基本状态信息&＃xff0c;这里面最有用是负载指标&＃xff0c;如果你还想查看当前系统的CPU/内存以及相关的进程状态&＃xff0c;可以使用TOP命令。

TOP

通过TOP命令可以详细看出当前系统的CPU、内存、负载以及各进程状态&＃xff08;PID、进程占用CPU、内存、用户&＃xff09;等。从上面的结果看出该系统上安装了mysql、java&＃xff0c;可以看到他们各自的进程ID&＃xff0c;假如这时Java进程占用较高的CPU和内存&＃xff0c;那么你就要留心了&＃xff0c;如果程序中没有计算量特别大、占用内存特别多的代码&＃xff0c;可能你的java程序出现了未知的问题&＃xff0c;可以根据进程ID做进一步的跟踪。除了通过TOP命令找到进程信息以外&＃xff0c;还可以通过jdk自带的工具JPS直接找到java程序的进程号。

JPS

可以看到jps命令直接罗列出了当前系统中存在的java进程&＃xff0c;这里第一个是jps命令自己的java进程&＃xff0c;而另外一个是我启动的nosql监控工具进程。通过这种方法查询到java程序的进程ID后&＃xff0c;可以进一步通过&＃xff1a;

top -p 3618 // 这里的3618就是上面查询到的java程序的进程ID

通过此方法可以准确的查看指定java进程的CPU/内存使用情况。

除此之外&＃xff0c;vmstat命令也可以查看系统CPU/内存、swap、io等情况&＃xff1a;

上面的命令每隔1秒采样一次&＃xff0c;一共采样四次。CPU占用率很高&＃xff0c;上下文切换频繁&＃xff0c;说明系统有线程正在频繁切换&＃xff0c;这可能是你的程序开启了大量的线程存在资源竞争的情况。另外swap也是值得关注的指标&＃xff0c;如果swpd过高则可能系统能使用的物理内存不足&＃xff0c;不得不使用交换区内存&＃xff0c;还有一个例外就是某些程序优先使用swap&＃xff0c;导致swap飙升&＃xff0c;而物理内存还有很多空余&＃xff0c;这些情况是需要注意的。

查看系统指标&＃xff0c;还有一个第三方工具&＃xff1a;pidstat&＃xff0c;这个工具还是很好用的&＃xff0c;需要先安装&＃xff1a;

yum install sysstat

该命令监控进程id为3618的CPU状态&＃xff0c;每隔1秒采样一次&＃xff0c;一共采样四次。“%CPU”表示CPU使用情况&＃xff0c;“CPU”则表示正在使用哪个核的CPU&＃xff0c;这里为0表示正在使用第一个核。如果还要显示线程ID&＃xff0c;则可以使用&＃xff1a;

pidstat -p 3618 -u -t 1 4

如果要监控磁盘读写情况&＃xff0c;这可以使用&＃xff1a;

pidstat还有其他的参数&＃xff0c;可以通过pidstat --help获取&＃xff0c;再次不再赘述。

下面再介绍几个JDK自带有用的工具&＃xff1a;jps、jstat、jmap、jstack。

jps&＃xff1a;上面我们已经使用过了&＃xff0c;他可以罗列出目前再服务器上运行的java程序及进程ID&＃xff1b;

jstat&＃xff1a;用于输出java程序内存使用情况&＃xff0c;包括新生代、老年代、元数据区容量、垃圾回收情况。

上述命令输出进程ID为3618的内存使用情况&＃xff08;每2000毫秒输出一次&＃xff0c;一共输出20次&＃xff09;

• S0&＃xff1a;幸存1区当前使用比例
• S1&＃xff1a;幸存2区当前使用比例
• E&＃xff1a;伊甸园区使用比例
• O&＃xff1a;老年代使用比例
• M&＃xff1a;元数据区使用比例
• CCS&＃xff1a;压缩使用比例
• YGC&＃xff1a;年轻代垃圾回收次数
• FGC&＃xff1a;老年代垃圾回收次数
• FGCT&＃xff1a;老年代垃圾回收消耗时间
• GCT&＃xff1a;垃圾回收消耗总时间

jmap&＃xff1a;用于输出java程序中内存对象的情况&＃xff0c;包括有哪些对象&＃xff0c;对象的数量。

jmap -histo 3618

上述命令打印出进程ID为3618的内存情况。但我们常用的方式是将指定进程的内存heap输出到外部文件&＃xff0c;再由专门的heap分析工具进行分析,例如mat&＃xff08;Memory Analysis Tool&＃xff09;&＃xff0c;所以我们常用的命令是&＃xff1a;

jmap -dump:live,format&＃61;b,file&＃61;heap.hprof 3618

将heap.hprof传输出来到window电脑上使用mat工具分析&＃xff1a;

jstack&＃xff1a;用户输出java程序线程栈的情况&＃xff0c;常用于定位因为某些线程问题造成的故障或性能问题。

jstack 3618 > jstack.out

上述命令将进程ID为3618的栈信息输出到外部文件&＃xff0c;便于传输到windows电脑上进行分析。

Windows环境下的监控工具

Windows环境下的监控工具也有很多&＃xff0c;但是本文主要推荐jvisualvm.exe、MemoryAnalyzer.exe&＃xff0c;有了他们其他工具几乎不需要了。

jvisualvm.exe在JDK安装目录下的bin目录下面&＃xff0c;双击即可打开。

双击左侧你需要监控的java程序即可对它进行监控&＃xff0c;这个工具包括对CPU、内存、线程、类都做了监控&＃xff0c;功能非常强大&＃xff0c;上文中介绍的所有功能&＃xff0c;其他在这个工具上都已经有了。当然怎么用、如何分析它需要花时间去一点点积累。

MemoryAnalyzer.exe&＃xff1a;上文我们已经提到&＃xff0c;常用于分析内存堆使用情况&＃xff0c;也是非常强大的工具。详细使用方法&＃xff0c;这里就不再赘述&＃xff0c;可以下载下来尝试一下。

上述介绍了基于Linux、Windows环境的监控工具&＃xff0c;有了这些工具我们就要利用他们做对应的事情&＃xff0c;下面将通过一个简单的案例&＃xff0c;说明如何使用他们。

案例分析

首先通过上述的介绍&＃xff0c;我们对故障排查流程应该有了一个印象&＃xff0c;这里先梳理出来&＃xff1a;

案例&＃xff1a;

 一个java应用启动以后&＃xff0c;使用人员发现应用不可用&＃xff0c;针对该现象我们做以下分析排查&＃xff1a;

1、首先查看服务器上的应用状态。使用jps命令查询当前在运行中的java进程&＃xff1a;

这里进程ID为6400的java应用就是我们刚启用的&＃xff0c;说明应用并没有挂掉&＃xff0c;还在运行中。

2、通过进程ID查询所占用的CPU、内存以及当前负载情况,top -p 6400。

从以上结果看出该应用并没有引起系统负载过高&＃xff0c;CPU、内存也没有出现异常情况。

3、通过上述结果我们推测因为内存原因引起的故障可性能较小&＃xff0c;所以我们优先排查线程栈&＃xff0c;使用jstack命令&＃xff0c;导出线程栈。

jstack 6400 > stack.out

我们将该文件传输出来便于查看。

查看线程栈可以看出&＃xff0c;主线程处于运行状态&＃xff0c;而子线程ThreadA、ThreadB、ThreadC、ThreadD一边在等待一个锁&＃xff0c;同时又持有另外一个锁&＃xff0c;其实看到这里我们基本推断该应用程序存在死锁&＃xff0c;因此造成线程等待&＃xff0c;应用不可用。通过以上栈的信息&＃xff0c;我们就可以到程序代码中详细查看代码了&＃xff0c;并且修改bug解决此问题。

死锁原理补充&＃xff1a;

如图所示&＃xff0c;造成死锁的原因是线程之间存在相互制约的情况&＃xff0c;而任一线程都无法继续执行。